Meeting EAA Requirements: Tools and Practices We Use at Vilmate

On June 28, 2025, the European Accessibility Act (EAA) comes into effect across all EU member states. This regulation introduces mandatory requirements for the accessibility of digital products and services.

The EAA applies to a wide range of solutions — including websites, mobile apps, e-books, online banking, and self-service terminals. Even if your company is based outside the EU, the law will still apply if you provide products or services to users in the European Union.

The requirements are based on international standards: WCAG 2.2 (Level AA) and EN 301 549. Non-compliance can lead to both legal risks and reputational damage.

In our first article, we explained what the EAA is, which products are affected, and why it’s important to start preparing early.

This article highlights tools that make accessibility a natural part of the development workflow. The Vilmate team uses them to support EAA compliance in real projects.

Implement Accessibility Linting

One of the easiest ways to improve accessibility in your codebase is to introduce linting rules focused on a11y. The good news? Most modern frameworks already have dedicated plugins for that.

• If you’re working with React, eslint-plugin-jsx-a11y is the standard choice.
• For Angular, there’s @angular-eslint/eslint-plugin-template.
• And for Vue, you can rely on eslint-plugin-vuejs-accessibility.

These plugins are built around established accessibility best practices and can be fine-tuned for your team’s specific needs. Once set up, they act as an early warning system—flagging potential issues before they become real problems.

To show how it works in practice, let’s use React as our starting point and walk through the setup of eslint-plugin-jsx-a11y.

To enable JSX:

1. Install the plugin:

2. Update your ESLint configuration to include the plugin:

3. If necessary, adjust the rules to match your project’s specific requirements.

Once configured, you can run the linter on your current codebase to identify and fix existing issues, aligning your project with current accessibility standards.

This approach helps identify and resolve accessibility issues early, even before they reach the development environment. It raises the overall accessibility level and reduces the risk of introducing new barriers for users.

CSS Accessibility Check: Stylelint

To meet the requirements of the European Accessibility Act (EAA), it’s essential to consider not only markup accessibility but also styles. Stylelint helps automatically detect CSS issues that can affect how users with disabilities experience your interface.

This tool is especially valuable for teams working on EAA-compliant interfaces, as it supports key principles of visual accessibility: contrast, readability, focus management, and responsiveness.

With stylelint-a11y, you can:

• Check the contrast between text and background;.
• Respect users’ system-level accessibility preferences;.
• Prevent focus outlines from being disabled;.
• Maintain consistent standards for scaling fonts and interface elements.

How to set it up:

1. Install the Plugin:

2. Add the stylelint-a11y plugin to your Stylelint configuration file:

3. Execute the linter to identify and fix accessibility issues:

Automated Accessibility Testing: Cypress and Axe

To meet the requirements of the European Accessibility Act (EAA) and avoid accessibility issues at later stages of development, it’s important to integrate accessibility checks directly into your testing workflow. One of the most effective ways to do this is by using Cypress in conjunction with the Cypress-Axe library.

This setup helps automatically detect accessibility issues before changes reach production. It ensures continuous EAA compliance as part of your CI/CD process, thereby speeding up team feedback loops.

How to integrate:

1. Begin by installing Cypress and the cypress-axe plugin

2. Configure Cypress to include the Axe accessibility tests:

3. Create E2E tests with accessibility checks:

These tests are easy to integrate into your workflow and generate reports on issues that violate WCAG 2.1 or 2.2.

After running the tests, your team receives a clear list of issues to address, including incorrect semantics, missing ARIA attributes, and focus-related problems. Fixing them is a key step toward meeting EAA technical requirements and creating a more inclusive digital product.

Husky: How to Catch Accessibility Issues Before You Commit

Even with well-configured linters, accessibility issues may still enter the codebase. Husky enforces pre-commit checks locally, ensuring that only compliant code is committed. This adds an extra layer of control before changes reach the remote repository.

When paired with ESLint and Stylelint, configured with accessibility rules, Husky helps enforce a consistent code style and catch common issues before they are committed to the repository.

How it works:

1. Add Husky to your project to manage Git hooks:

2. Enable Git hooks with Husky

3. Add linting configuration to package.json

4. Create a pre-commit hook that runs ESLint and Stylelint:

From that point on, every commit will automatically trigger linting. If accessibility issues are found in the code, including JSX, templates (HTML), or CSS — the commit will be blocked until they’re resolved.

This process helps keep your project aligned with WCAG and EN 301 549 standards — avoiding last-minute surprises before release.

Storybook + addon-a11y: Visual Accessibility Testing for UI Components

In large projects that use a design system, it’s important to check accessibility not only for full pages but also for individual components. Storybook helps with this by letting you test both feature components and shared UI elements separately.

With this tool, you can visually test components for key accessibility requirements, including heading structure, semantic HTML, and the correct use of ARIA attributes. It’s beneficial for achieving EAA compliance early — even before components are integrated into the product.

How to set it up:

1. Add the @storybook/addon-a11y package to your project:

2. Include the addon in .storybook/main.js:

3. Restart Storybook — you’ll now see an Accessibility tab in the UI that highlights warnings and errors.

You’ll receive real-time reports on common issues — such as low contrast, missing ARIA attributes, or semantic HTML violations. This feedback allows you to quickly identify and fix problems, from adding missing labels to correcting markup structure. Once updated, you can immediately re-test the component in Storybook to confirm the issue is resolved.

This approach makes accessibility checks a natural part of daily component development — not something postponed until final testing.

Turning EAA Requirements into a Sustainable Development Practice

The European Accessibility Act is a game-changer: making accessibility not just an ethical choice but a legal obligation. For companies building digital products, it presents an opportunity to rethink development practices and integrate accessibility at a systemic level.

The tools and practices we’ve covered aren’t one-off fixes — they form the foundation of a sustainable and scalable approach. They help identify and resolve issues early, reduce risks, and ensure your product meets the expectations of auditors, users, and regulators alike.

At Vilmate, our team actively applies these tools across client projects. We know how to build processes that align with EAA requirements, and we’re ready to support you at any stage, from setting up linters to performing complete compliance assessments.

If you want to be confident your product meets accessibility standards, we’re here to help you implement it most effectively.